As you surely noticed, early in the year we published together with TeaTime with Testers the first State of Testing Survey report, showing some interesting information about the current state of our testing community and raising additional questions about where are we heading as a profession.
We are now honored to have two world renowned testing experts such as Jerry Weinberg and Fiona Charles who will join Lalitkumar Bhamare and myself (Joel) in reviewing some of the most interesting answers to our survey in order to further analyse them and reach conclusions about the present and future state of our global testing community.
Please use this link to sign up for this webinar, taking place on Thursday April 24th at 2 PM MDT.
When we are happy we feel that the day is bright, that we can climb the stairs by jumping two of them at a time, and that everything we do will simply come out right.
When we are down we feel that even the air is heavier and harder to breath. Some of us may also feel that regardless what we say or do nothing will come out right.
These are the days when we think to ourselves that it might be better to stay in bed with our eyes shut so that nothing will become even worst than it already is – and yes, things can always be worse than they are right now…
Your mood affects your testing
It is obvious that your mood will affect your work if you are in direct interaction with your customers. You have experience this when shopping in a store, traveling and needing assistance from someone from the crew, or simply by calling to get some sort of phone assistance. You can clearly discern when the person in front of you is having a good or a bad day.
This is also true when your work is done in relative isolation from your customer, as it is in the case of testing.
When you are in a somber mood you will not only work slower, but you will also be more narrow minded on the scenarios and paths you take while running your tests, and this can cause you to miss some important bugs within the app you are testing.
On the other hand when you are in an extremely good mood your testing will be more active and it will flow in more directions at one, not to mention it will be quicker and “lighter”. This can also cause you to be more overconfident and less patient in your work, and so you may also miss important tests and bugs in the application.
Its not only about your mood but about how you feel in general
OK, so you cannot be too happy or too sad to test. But did you know that your feelings towards people also affect your testing in additional ways?
For example, when you have a negative feeling towards one of your developers (or development teams) this will come forward in your testing.
In a positive sense you will be more thorough and cautious when you test their stuff because “you know they don’t work well” and so you will find many bugs in the features they deliver. In a negative sense, you will be biased to report every single thing you find as a critical bug (and not as a regular or low level bug) simply because you are “sick and tired of the way these guys work” and not because of any subjective criteria.
Something similar can also happen when you test something by team you “really like”.
In this case you may find yourself investing less in your tests because “you know these guys are very careful and they surely tested all the scenarios themselves”, right…? And when you find a bug you may also report it with a lower priority because you don’t want to put these guys on the hot-seat for delaying the release date – after all it is only a small bug (or so you want to believe).
Leaving your emotions outside the testing lab
Regardless of how you look at it, when you start testing you need to leave your emotions outside the lab.
It is not professional to change the way you look at an application depending on who wrote it, and you cannot let your mood get in the way of how you will test something on a given day.
I know this is easier said than done, I am also influenced by the way I feel. But there are some techniques that can help you cope with this and limit the way you are affected by any unrelated factors.
The best pieces of advice I’ve got around this point is to learn to enter your “testing zone” before you embark on your work. I wrote about this point in this post a while back.
There are also techniques around testing blindly without knowing who wrote the things you are testing right now, and even some that suggest you should only test things from other teams (although I find both these techniques a little theoretical and impractical).
The bottom line is to take this into account
I think that in the end of the day the best thing we can do is to know that our emotions will generally cause us to be biased, and with this in mind we need to examine ourselves before starting a testing task to make sure we can actively correct for these emotions by being more aware of them and not letting ourselves fall into the traps I mentioned above.
Are you emotionally biased?
I am wondering how many of you have experienced things like these.
If you have please share your story with us!
Also tell us if you have other techniques you use in order to leave your feelings outside the testing lab.
We are looking for volunteers to join the small infra team here at the Jenkins project. We are the butlers of the butler that get Mr.Jenkins going.
We've been managing our servers through puppet, and have been slowly folding pieces one at a time to puppet, but there's still a lot of snowflake services that need proper operationalization.
So to fix them up, PuppetLabs folks generously agreed to help us get going with a deployment of Puppet Enterprise. Tyler has managed to arrange a "rapid deployment" engagement. To kick start the effort, an instructor would come for one week (April 28th-May 2nd) to bring us up to speed on modern Puppet. we'll then spend some time on our own to puppt-ize more, and deploy Puppet Enterprise.
The end goal is to ensure sustainability of our infrastructure, in case of unexpected server loss.
As we are about to get this effort going, we think this is a good time to solicit a few more volunteers. We are looking for someone who could join this two week engagement in San Francisco, and keep their involvement beyond that. This is a part time volunteer work, and you'd get some visibility and exposure to the inner guts of open-source projects, not to mention the satisfaction of getting thanked for your work.
If you are interested, please drop us a note at the infra list.
Bugsnag is a web and mobile error monitoring application that detects and diagnose crashes within your applications. They recently informed us about their new Assembla integration that can create Assembla tickets for detected errors allowing your team to quickly start squashing these errors via Assembla tickets.
To set up this integration, you will first need to have a Bugsnag project up and running. To try Bugsnag out, you can sign up here. From your Bugsnag project, visit the Settings > Notifications section to enable the Assembla integration. Once enabled, you will land on the integration configuration page that look like this:
Determine when an Assembla ticket should be created: when the first exception of a new type (error) occurs, when a previously resolved error re-occurs, and/or when you manually click on “Create Issue” on an error within Bugsnag.
Space URL: Such as https://www.assembla.com/spaces/space_name/tickets
Your API Key and API Secret: This can be created in your Assembla profile sidebar menu, or by following this link.
Tags (optional): This provides a default tag for all Assembla tickets created from Bugsnag such as “Bugsnag Error.” I personally love this part of the integration because with tag filters, you can easily see all errors that are being worked on and where they stand. To learn more about Assembla’s tag feature, check out our release announcement.
To learn more about other companies that have integrated with Assembla or to submit an integration for review, check out www.assembla.com/integrations.
You’ve tested every aspect of your mobile app – functionality, usability, security, performance and other types. You’ve tested it with simulators and in the wild. You think you’ve covered almost every angle and that it’s essentially bulletproof, but you forgot the biggest cause of app failure: People.
Yeah, those guys. According to PC World, nearly 80 percent of the vulnerabilities discovered in mobile apps are not the fault of the application code itself, but rather the result of human error.
According to the HP 2013 Cyber Risk Report, though, the application itself is not to blame for most vulnerabilities—you are. HP compiled data from 2,200 applications scanned by HP Fortify on Demand and reports that 80 percent of the vulnerabilities discovered were not the fault of the application code itself.
“Many vulnerabilities were related to server misconfiguration, improper file settings, sample content, outdated software versions, and other items related to insecure deployment,” the report states.
In other words, it’s not your fault! That said, there are some things you can do as testers and developers to minimize the risk of human error. Let’s take a closer look at some the causes mentioned in the article:
Both the iOS and Android platforms give developers the ability to encrypt data that’s stored within the mobile app. The problems is, many developers neglect to include this feature and many testers fail to account for it as well. These days, apps that do NOT store some type of personal data are the exception, so if you want to save users from themselves, it’s best to consider encryption as the default option.
Outdated Software Versions
The latest version of your app probably includes a number of security updates, as well as some new features. But guess what? Most users are slow to update their software and apps, which means that in the meantime, they are susceptible to all of the weaknesses in your previous versions. Thus, when you update your app, make it count – and make users aware of the consequences of not updating.
Passwords and Permissions
If your mobile app provides unnecessary default settings – such as a password or username – then your mobile app could be at risk for a security breach. When this functionality exists, it’s possible for a hacker to bypass the log-in process and access both the personal, sensitive information of other users. Of course, many apps do require this feature (and many users will have weak passwords) but if it’s an unnecessary aspect of your app, perhaps you should consider ditching it.
No matter how much preparation your company may devote to development and testing, your users will find a way to ruin it (and possibly damage your reputation in the process). While you cannot account for every instance of human error, it’s your job as software quality professionals to be aware of the many ways in which a user can injure themselves. The items mentioned above are just a start.
What are some other ways that human error leads to app quality issues? Be sure to let us know in the comments section below.
Have you seen our Test All The Things t-shirts on the twitterverse yet? We get a lot of compliments on them (thanks, we’re blushing) and a lot of requests for them, too. Although they’re not available for purchase on the site, we thought we’d do a fun giveaway for a couple of lucky winners. Plus you never know, you could get a few spicy accoutrements to go with it.
The contest is easy. Rules below:
- If you’re not already doing so, follow us on Twitter: @saucelabs
- Then, retweet the embedded tweet below OR any more updates that we post about this contest on Twitter. Bonus points for including our hashtag, #TestAllTheThings, and for using our handle, @saucelabs.
- A lucky person who’s retweeted one of our contest messages will win a care package.
- Our 5,000th follower will also win a care package.
- The more often you retweet us or mention the contest, the better! Hey, we never said we weren’t biased.
- Both retweets and modified tweets will be counted.
- Contest will close on May 15 or after we get our 5,000th follower; whichever comes first.
- We’ll notify winners via direct message on Twitter.
You know you want it! Good luck, Saucers.
Follow us and retweet this message for a chance to win gift package from Sauce Labs!
— Sauce Labs (@saucelabs) April 18, 2014
The first time I heard from Sublime was at the MVP Summit in February 2013. There was one big proponent of Sublime and one big room that wasn’t that interested. Things moved on but the name was there.
Today, I’m hearing more and more about Sublime and the community around it has grown incredibly.My pains so far…
First, the shortcut. I’m used to Visual Studio + ReSharper and oh god… the shortcuts are killing me. My brain is hardwired since at least 3-4 years in using ReSharper + VS shortcuts and to be honest… it’s the most horrible experience I have so far. However, I know that shortcut are mainly muscle memory. You think of an operation and your body knows exactly what to press without you even thinking about it. Rename? Boom. My fingers are on CTRL-R before my brain can remember the exact shortcut. This I know is going to be a world of hurt for me until my stupid brain get used to this.
Since we’re talking shortcuts…Surviving Sublime with some shortcuts
With ReSharper, you can get very far with CTRL-ENTER (fix whatever is where I am) and CTRL-SHIFT-R (refactor).
So I was looking for something similar with Sublime.Shortcut Action Description CTRL-P Quick-Open files Allows you to type file names with paths to allow you to get anywhere. Supports PascalCasing and partial match. CTRL-SHIFT-R Go to Symbol Gets you to a recognized symbol. Symbols can be created by custom packages (more on that later). Sublime will find symbols in your files. CTRL-SHIFT-P Command prompt This one is the power tool you are going to use once you get used to Sublime. It allows you to access commands from packages. For a more complete list of shortcuts, I recommend going here. Sublime and its packages
If like me you are coming from a Visual Studio environment, you should know NuGet. Well, Sublime has its equivalent but for the editor itself.
Click here for the instructions on getting Sublime ready to install packages. It will give you instructions on getting it ready.
So what can packages do? They can add supports for new languages, help the IDE find new Symbols, add snippets per languages, add commands, etc. A package can potentially do anything inside your project.
Some plugins like LiveReload will automatically refresh your browser when you save a file. The Git plugin will add git commands to the CTRL-SHIFT-P interface so that you don’t even have to leave your editor to git commit. You like the TODO list in Visual Studio? TodoReview generates a list of all todos in your project in any languages.
If there is something you want to do… there’s probably a Sublime Package for it.
Okay those are completely crazy once you start using them but is still quite a relatively simple concept.
As an example, I installed a JSLint package and suddenly, I have a JSLint command available that I can run on any files.Conclusion
Part 1 of 3 in a Blog Series: ‘How Your Software is Like a Car’
Part 1: It’s Just the Way Software is Made
Today software runs the things that run our world. In fact, I’m starting to see the pundits talk not just about the Internet of Things, but about the Internet of Everything. With software so deeply embedded in every aspect of our lives, the companies running the software are accountable for protecting the consumers using it. In fact, it is just a matter of time before software liability becomes a reality (but that is a topic for another day).
Just like automobile manufacturers, software “manufacturers” need to apply supply chain management principles for both efficiency and quality. They need to be prepared to conduct a rapid and comprehensive “recall” when a defect is found. And today’s modern development practices make this, well, challenging to say the least.
Bear with me a moment, as I take you through a quick history of Toyota’s supply chain innovations … then I promise to bring this back to your software supply chain.
Toyota Transforms and Outperforms (Laying Agile Foundations)
In 1926, Sakichi Toyoda founded Toyoda Automatic Loom Works. From the start, he obsessed over efficiency and automation. He invented and ran the most advanced looms in the world – delivering dramatic improvements in quality and a 20-fold increase in productivity. Perfection and efficiency were so ingrained in his production processes, his looms stopped automatically whenever a thread broke, for example.
When Sakichi’s son, Kiichiro, decided to move from textiles to auto manufacturing, the apple did not fall far from the tree. Kiichiro set about optimizing everything conceivable in the production of automobiles. His production innovations, eventually called the Toyota Production System (TPS), gave rise to Lean Manufacturing and Supply Chain Management principles.
Today, the effect of these principles on Toyota’s efficiency is remarkable. Company-wide, Toyota has a total of 226 suppliers while GM has more than 5,000. Toyota produces only 27% of the content of their vehicles while GM produces more than 54% of theirs. That means GM has twenty times the suppliers but still produces twice as much of their vehicles. The result? A Chevy Volt sells for nearly double the price of the Toyota Prius while the Prius outsells the Volt nearly fifteen to one.
The First Wave: Toyota’s Principles Drive the Innovations in Agile
Toyota’s principles not only improved auto manufacturing, but also extended to many other industries including software development. As early as 2000, Fujitsu Software Technologies — desperate to improve productivity and overcome IT budget deflation in the post-bubble economy — decided to experiment with applying TPS Lean Manufacturing to software development. This effort led to a wave of innovation in agile software development. A success that, in hindsight, is not at all surprising.
The Second Wave: Agile Meets Component-Based Development
Where Agile methods were based on iterative and incremental development (embracing Toyota’s lean manufacturing principles), Fujitsu did not do a whole lot with Toyota’s supply chain management innovations (sourcing reliable and thoroughly tested “parts” that serve your people and processes). This is where another transformational change in the software development ecosystem is just beginning to come into play: the use of open source and the embrace of component-based software development. That is, where agile software development must meet supply chain management.
Today, 90% of a typical application is composed of open source and third party components. The open source community is the dominant supplier of software building blocks, the components they develop feeding virtually all software development “supply chains”. These components are sourced within the supply chain by software development organizations, usually from public repositories.
To give you a sense of the scale of operations in today’s software ‘manufacturing’ supply chains, the largest source of Java components known as the “Central Repository” clocked in 13 billion downloads last year alone – more than 35 million components every day (and that dramatically understates real usage because more than a quarter of the download requests came from local component repositories — such as Nexus – that are in turn accessed by teams of developers).
Today’s reality: software assembly (together with agile) is just the way software is made.
In the next part of this blog series, we’ll take a drive down the software supply chain to help you understand where your software has really come from.
I talked at TestBash about context-driven testing in agile. I my talk I said that I refuse to do bad work. Adam Knight wrote a great blog post “Knuckling Down” about this: “One of the messages that came up in more than one of the talks during the day, most strongly in Huib Schoots talk on Context Driven in Agile, was the need to stick to the principle of refusing to do bad work. The consequential suggestion was that a tester should leave any position where you are asked to compromise this principle.”
Adam also writes: “What was missing for me in the sentiments presented at TestBash was any suggestion that testers should attempt to tackle the challenges faced on a poor or misguided project before leaving. In the examples I noted from the day there was no suggestion of any effort to resolve the situation, or alter the approach being taken. There was no implication of leaving only ‘if all else fails’. I’d like to see an attitude more around attempting to tackle a bad situation head on rather than looking at moving on as the only option. Of course we should consider moving if a situation in untenable, but I’d like to think that this decision be made only after knuckling down and putting your best effort in to make the best of a bad lot.”
Interesting because I think I said exactly that: “if anything else fails, leave!” But maybe I only thought that and forgot to speak it out loud, I am not sure. Let’s wait for the video that will give us the answer. But in the meanwhile: of course Adam is right and I am happy that he wrote his blog post. Because if I was too firm or too distinct, he gave me a chance to explain. Because looking back, I have done many projects where, if I hadn’t tried to change stuff, I would have left many of them in the first couple of days. There is a lot of bad testing around. So what did I try to say?
This topic touches very closely to ethics in your work! Refusing to do bad work is an ethical statement. Ethics are very important for me and I hope more testers will recognize that only being ethical will change our craft. Ethics help us decide what is right and what is wrong. Have a look at the ethics James Bach summed up in this blog post “Thoughts Toward The Ethics of Testing“. Nathalie pointed to an article she wrote on ethics in a reply to my last post.
Ethics and integrity go hand in hand. Ethics are the external “rules and laws” and integrity is your internal system of principles that guides your behaviour. Integrity is a choice rather than an obligation and will help you do what is right even if no one is watching.
I refuse to do bad work!
Bad work is any work that is deliberately bad. I think along the lines of restrictions in a context, demands placed on them that they don’t know how to handle. Or even worse: intentionally doing stuff you know can be done better, but it is faster, easier or because others ask you to do it like that. Of course there are novices in the field and they do work that can be done better. I do not call that bad work since they are still learning. Still there is a limit to that as well. If you have been tester for several years and you still do not know how to do more than 3 test techniques without having to look them up, I will call that bad work as well. I expect continuing professional development from everybody in the field. Simply because working in IT (but in any profession) we need to develop ourselves to become better.
Lying is always bad work. And I have seen many people lie in their work. Lying to managers to get off the hook, making messages sound just a little better by leaving out essential stuff. Also telling people what they what to hear to make them happy is bad work. What do you do when your project manager asks you to change your test report because it will harm his reputation? Or what do you tell the hiring manager in a job interview when he asks you if you are willing to learn? Many people tell that they are very willing to learn, but are they really?
Bad work is claiming things you can’t accomplish: like assuring quality or testing everything. It is also bad work when you do not admit your mistakes and hide them from your colleagues. Bad work is accepting an assignment when you know you do not have the right skills or the right knowledge. In secondment assignments this is an issue sometimes. I have taken on a project once where the customer wanted something I couldn’t deliver but because my boss wanted me on the position I accepted. That was wrong and the assignment didn’t work out. I felt very bad about it: not because I failed, but because I knew upfront I would fail! I won’t do that again, ever.
So how do I handle this?
I push back! Of course I do not run away from a project when I see or smell bad work. I do try to tackle the challenges I am faced with. I use three important ways trying to change the situation: my courage, asking questions and my ethics. Some examples: when a managers start telling me what I should do and explicitly tell me how I should do that, I often ask how much testing experience the manager has. When given the answer I friendly tell him that I am very willing to help him achieve his goals, but that I think I am the expert and I will decide on how I do my work. Surely there is more to it and I need to be able to explain why I want it to be done differently.
I also ask a lot of questions that start with “why”. Why do you want me to write test cases? What problem will that solve? I found out that often people ask for things like test cases or metrics because it is “common practice” or folklore not because it will serve a certain purpose. Also when I know the reasons behind the requests, it makes it easier to discuss them and to push back. A great example of this is the last blog post “Variable Testers” by James Bach.
Adam talks about changing peoples minds: “One of the most difficult skills I’ve found to learn as a tester is the ability to justify your approach and your reasons for taking it, and being able to argue your case to someone else who has a misguided perspective on what testing does or should involve. Having these discussions, and changing peoples minds, is a big part of what good testing is.”
I fully agree. In my last on blog post “heuristics for recognizing professional testers” my first heuristic was: “They have a paradigm of what testing is and they can explain their approach in any given situation. Professional testers can explain what testing is, what value they add and how they would test in a specific situation.” To become better as testers and to advance our craft, we should train the skills Adam mentions: justify approach and being able to argue our case.
It will make you better and happier!
Jerry Weinberg listed his set of principles in a blog post “A Code of Work Rules for Consultants“. In this blog post he says: “Over the years, I’ve found that people who ask these questions and set those conditions don’t wind up in jobs that make them miserable. Sometimes, when they ask them honestly they leave their present position for something else that makes them happier, even at a lower fee scale. Sometimes, a client manager is outraged at one of these conditions, which is a sure indication of trouble later, if not sooner.”
It will make you a happier person when you know what your limits are and you are able to clearly remind people you work with. It will prevent you from getting into situations that make you miserable. “That’s the way things are” doesn’t exist in my professional vocabulary. There is always something you can do about it. And if the situation you end up in, after you tried the best you can, isn’t satisfying to you: leave! Believe me, it will make you feel good. I have got the t-shirt! And… being clear about your values also will make you better in your work. Maybe not directly, but indirectly it will.
Daniel Pink speaks about the self-determination theory in his book “Drive“. The three keywords in his book are: Autonomy, Mastery and purpose: “human beings have an innate drive to be autonomous, self-determined and connected to one another, and that when that drive is liberated, people achieve more and live richer lives” (source: http://checkside.wordpress.com)
But but but….
Of course I know there is the mortgage and the family to support. Maybe it is easy for me to refuse bad work. Maybe I am lucky to be in the position I am. But think again… Are you really sure you can’t change anything? And if your ethics are violated every day do you resign yourself? Your ethics will act as heuristics signalling you that there is a problem and you need to do something. I didn’t say you have to leave immediately and if you are more patient than I am, maybe you do not have to leave at all… But remember: for people who are good in what they do, who are confident in what they will and will not do and speak up for themselves, there will always be a place to work.
Have you even thought about integrity? What are your guiding principles, values or ethics? What would you call bad work? And what will you do next time when somebody asks you something that conflicts with your ethics?
While reading stuff online about (refusing) bad work I ran into this blog post by Cal Newport about being bad at work: “Knowledge Workers are Bad at Working (and Here’s What to Do About It…)“Interesting enough Cal Newport wrote a book called “So Good They Can’t Ignore You: Why Skills Trump Passion in the Quest for Work You Love” about the passion hypothesis in which he questions the validity of the hypothesis that occupational happiness has to match per-existing passion. In several recent talks and blog posts I did I talk about passion. Also in the talk discussed in this blog post I claim that passion is very important and I show a fragment of the Stanford 2005 commencement speech by Steve Jobs. Exactly the passage I showed in my talk, Cal uses in the first chapter of his book. “You’ve got to find what you love. And that is as true for your work as it is for your lovers. Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do. If you haven’t found it yet, keep looking. Don’t settle. As with all matters of the heart, you’ll know when you find it. And, like any great relationship, it just gets better and better as the years roll on. So keep looking until you find it. Don’t settle.” Anyway. Interesting stuff to be researched. I bought the book and started reading it. To be continued…
Sick of maintaining test infrastructure? Can’t keep up with supporting the latest Firefox or Chrome? Let Sauce help! We’re on a mission to make testing mobile and web applications fast, easy and affordable for developers.
This is going to be a quick rant post, hopefully. Today I saw another Kanban board which had a “Read for test” column on it, here’s the screenshot:
I Think “Ready For” Columns Are Baaaaad
With most Kanban boards you mark a card as done when it’s ready to be pulled into another column. If that means it has to be deployed before a card is ready for test then so be it. The last thing we want is cards just sitting around waiting – this is baaaaaad. “Ready for Test” usually means it’s either deployed (and yet to be tested) or waiting to be deployed. Either way, not much is happening to the work sitting in this column. Basically it’s waste (or “muda” as the Lean Kanban aficionados might call it), and remember, waste is baaaaad.
Seriously, I Think They’re Baaaaad
A result of using these “Ready For x” columns is that they tend to slightly move us away from the “stop the line” practice that good Lean/Kanban systems employ. Basically whenever there’s a problem, or a bottleneck is appearing, we want to stop the production line and address the issue. So, if we keep all these “Ready for QA” cards in our In Dev or Code Review Column (basically whatever column comes before your Ready for QA column) then we’ll very quickly reach our WIP (Work In Progress) limit and the line will be stopped. That’s a good thing! We want to catch that bottleneck as soon as we can, we don’t want to hide it by pushing our cards into another “buffer” column.
Did I Mention That I Think “Ready For” Columns in Kanban Are Baaaaaad?
Yet another problem with “Ready for x” columns is that they quite often tend to be push rather than pull columns. You can’t really pull into a Ready for QA column as it isn’t an actual “workflow” state, it’s a “wasteflow” state (see what I did there?). I mean, who’s going to pull stuff into that column anyway? I’ve yet to meet a “ready for test” team who just sit around pulling cards into their column before marking them as “ready” (presumably once they’ve verified that they are indeed ready for test). Ok, you might have a deployment team who are responsible for deploying stuff to your test environments and so forth. In this case, your workflow state still isn’t “Ready for test” it’s “In Deployment”.
“Ready for x” columns make baby Jesus cry.
With the recent file search improvements, it is now easier to find the files you are looking for when you need them. With every file upload, we now index all the following elements: file name, tags, mime-type (media type), and author.
- File Name: We now apply a word delimiter filter that splits words into subwords based on intra-word delimiters such as case transitions ("PowerShot" → "Power", "Shot"), letter to number transitions ("SD500" → "SD", "500"), and characters ("Wi-Fi" → "Wi", "Fi").
- Tags: If you add the optional tags to a file, you can easily include a tag in the search parameters to locate the file.
- Mime Type (Media Type): When a file is uploaded, it will be indexed with a media type such as hello.png will include “image/png” so it can be found with a search for “hello” or “image” or “png” or any combination like “hello image.” Almost all files have a mime type such as word, excel, zip, pdf, etc., and we now index them so you can locate your files easier.
- Author: The author field consists of the user’s first name and last name as displayed in their profile as well as username. Usernames are also use the same word delimiter to split usernames into subwords. So if John Smith with username JohnRocks uploads a file, you can search for that file with “john” or “smith” or “johnrocks” or even just “rocks.”
Most importantly, the default logical search operation has changed to search for words using AND instead of OR when using a combination of words. For example, when you search “john image” it will return back anything that is an image AND that was uploaded by John.
We hope these improvements make file searching more efficient. If you have any other suggested improvements, please let us know on our feedback site.
Check out some other Assembla tips and tricks!
During the 2-day training workshops participants learn about the fundamentals of test automation and get to practice how to use Ranorex tools hands-on.
09:00AM - 04:30PM GMT
09:30AM - 05:00PM CET
Please have a look at the upcoming training events schedule for the complete schedule.
We look forward to seeing you there!
Kendo UI Core (www.telerik.com) – Kendo is now open source!.NET