With BugBuster v3, all users get now in their subscription for free a full-fledged test scenario recorder. This recorder is a Chrome extension available on the Chrome store.
Using this extension you don’t need to be an engineer to create technical and functional test scenarios in minutes for your web application. And without writing a single line of code!Opening a BugBuster Trial account
Go to app.bugbuster.com and sign up for a Trial account. The trial account lasts 14 days and can be extended upon request.
Using Google Chrome, go to the Chrome Store and install the extension by clicking on the blue FREE button.
The Scenario Recorder is now ready to be linked to your BugBuster account.
Last step is to connect the Scenario Recorder to your BugBuster account. You will then be able to export test scenarios automatically right from the extension.
You need first to navigate to the Profile page then copy the API key
Then paste it into the Your API Key field in the Settings section of the extension. Finally click on Go to recordings to complete the process.
Congratulations, you are now ready to create test scenarios for your web application!Watching the extension in action
In the following video we demonstrate how to create a test scenario to make sure that a visitor would be able to create a new account on a Magento website. The whole scenario is generated using the Recorder thus without writing a single line of code.
Please let us know what you think of this Scenario Recorder on Twitter or leave us a comment below. The more we share the better the Scenario Recorder will get!
The post BugBuster v3: How to install the Scenario Recorder Chrome extension appeared first on BugBuster.
From the windy city to a rockstar developer, we salute a couple fantastic .NET coders who know how to strike the right (or Wright) chord! Great work John and Brian.John Wright
John Wright is a software engineer with experience developing for large, distributed networks using multiple platforms and technologies based in the greater Chicago area. He has a wide experience with software development and management across the entire development lifecycle, including requirements gathering and analysis from direct customer discussions, design, development, testing and release. Check out his blog (http://www.wrightfully.com/) as a way to keep note of interesting topics he comes across in his day-to-day work, at community meetings and events, or opinions on the technology industry and related topics. You can also catch his ramblings on twitter @Wright2TweetBrian Canzanella
I am very pleased to announce that my “Agile Adoption Roadmap” Blog has just reached 100,000 hits. This is a great milestone and it makes me happy that there are so many professionals curious about Agile including many Agile enthusiasts, advocates, champions, coaches who are visiting and even commenting on my articles. It highlights that the many articles have value. If you want to receive its value, consider following this blog at: http://cmforagile.blogspot.com/.
To add to the statistics, I have folks from 45 different countries that have visited my site. The top 10 countries include: United States, United Kingdom, India, Russia, Germany, Canada, France, Australia, Ukraine, and China. Other countries that have significantly visited my site are: Sweden, Poland, Spain, Finland, South Africa, Iran, Norway, Iraq, Romania, Brazil, Argentina, Belarus, Malaysia, Portugal, Netherlands, Switzerland, and Italy.
The Agile Adoption Roadmap blog provides the reader with a range of topics related to adopting Agile within their teams and organizations. The content has a special emphasis on “being Agile” and bringing the Agile mindset to your work. I have written and posted 56 articles to date (although this one technically counts as the 57th). What are some of the top articles that Agile, IT, and Business Professionals have found of value? The top articles include:
- Who makes the best Scrum Master
- Agile Animal Farm – Pigs, Chickens, and more
- Agile Value Capture Metrics – Are you building value?
- Right-sizing Documentation in an Agile World
- Agile Definition of Done Starter Kit
- Agile – Its more disciplined than you think
- Gamification of your Agile Journey
- Agile Culture – Are you stepping up?
- The Role of Middle Management in an Agile World
- Are you Ready for your Agile Journey?
- Agile Executive Playbook
- Robust Agile Requirements – Its about the Discussion
- Is it finally time to “Be Agile”?
- Personas – Do you really know your Users?
- User Story Writing Starter Kit
- Agile Lagging to Leading Metric Path
I’m tired of hearing the simplistic advice about how to listen one must not talk. That’s not what listening means. I listen by reacting. As an extravert, I react partly by talking. Talking is how I chew on what you’ve told me. If I don’t chew on what you say, I will choke or get tummy aches and nightmares. You don’t want me to have nightmares, do you? Until you interrupt me to say otherwise, I charitably assume you don’t.
Below is an alternative theory of listening; one that does not require passivity. I will show how this theory is consistent the “don’t talk” advice if you consider that being quiet while other people speak is one heuristic of good listening, rather than the definition or foundation of it. I am tempted to say that listening requires talking, but that is not quite true. This is my proposal of a universal truth of listening: Listening requires you to change.
To Listen is to Change
- I propose that to listen is to react coherently and charitably to incoming information. That is how I would define listening.
- To react is to change. The reactions of listening may involve a change of mood, attention, concept, or even a physical action.
Notice that I said “coherently and charitably” and not “constructively” or “agreeably.” I think I can be listening to a criminal who demands ransom even if I am not constructive in my response to him. Reacting coherently is not the same as accepting someone’s view of the world. If I don’t agree with you or do what you want me to, that is not proof of my poor listening. “Coherently” refers to a way of making sense of something by interpreting it such that it does not contradict anything important that you also believe is true and important about the world. “Charitably” refers to making sense of something in a way most likely to fit the intent of the speaker.
Also, notice that coherence does not require understanding. I would not a bad listener, necessarily, if I didn’t understand the intent or implications of what was told to me. Understanding is too high a burden to require for listening. Coherence and charitability already imply a reasonable attempt to understand, and that is the important part.
Poor listening would be the inability or refusal to do the following:
- take in data at a reasonable pace. (“reasonable pace” is subject to disagreement)
- make sense of data that is reasonably sensible in that context, including empathizing with it. (“reasonably sensible” is subject to disagreement)
- reason appropriately about the data. (“reason appropriately” is subject to disagreement)
- take appropriate responsibility for one’s feelings about the data (“appropriate responsibility” is subject to disagreement)
- make a coherent response. (“coherent response” is subject to disagreement)
- comprehend the reasonable purposes and nature of the interaction (“reasonable purposes and nature” is subject to disagreement)
Although all these elements are subject to disagreement, you might not choose to actively dispute them in a given situation, because maybe you feel that the disagreement is not very important. (As an example, I originally wrote “dispute” in the text above, which I think is fine, but during review, after hearing me read the above, Michael Bolton suggested changing “dispute” to “disagreement” and that seemed okay, too, so I made the change. In making his suggestion, he did not need to explain or defend his preference, because he’s earned a lot of trust with me and I felt listened to.)
I was recently told, in an argument, that I was not listening. I didn’t bother to reply to the man that I also felt he wasn’t listening to me. For the record, I think I was listening well enough, and what the man wanted from me was not listening– he wanted compliance to his world view, which was the very matter of dispute! Clearly he wasn’t getting the reaction he wanted, and the word he used for that was listening. Meanwhile, I had reacted to his statements with arguments against them. To me, this is close to the essence of listening.
If you really believe someone isn’t listening, it’s unlikely that it will help to say that, unless you have a strong personal relationship. When my wife tells me I’m not listening, that’s a very special case. She’s weaker than me and crucial to my health and happiness, therefore I will use every tool at my disposal to make myself easy for her to talk to. I generally do the same for children, dogs, people who seem mentally unstable, fire, and dangerous things, but not for most colleagues. I do get crossed up sometimes. Absolutely. Especially on Twitter. Sometimes I assume a colleague feels powerful, and respond to him that way, only later to discover he was afraid of me.
(This happened again just the other day on Twitter. Which is why it is unlikely you will see me teach in Finland any time soon! I am bitten by such a mistake a few times a year, at least. For me this is not a reason to be softer with my colleagues. Then again, it may be. I struggle with the pros and cons. There is no simple answer. I regularly receive counsel from my most trusted colleagues on this point.)
A Sign of Being Listened to is the Change that Happens
Introspect for a moment. How do you know that your computer is listening to you? At this moment, as I am typing, the letters I want to see are appearing on the screen as I press the keys. WordPress is talking back to me. WordPress is changing, and its changes seem coherent and reasonable to me. My purposes are apparently being served. The computer is listening. Consider what happens when you don’t see a response from your computer. How many times have you clicked “save” or “print” or “calculate” or “paste” and suffered that sinking feeling as the forest noises go completely silent and your screen goes glassy and gets that faraway grayed out look of the damned? You feel out of control. You want to shout at your screen “Come back! I’ve changed my mind! Undo! Cancel!” How do you feel then? You don’t say to yourself “what a good listener my computer is!”
Why is this so? It’s because you are involved in a cybernetic control loop with your computer. Without frequent feedback from your system you lose your control over it. You don’t know what it needs or what to do about it. It may be listening to something, but when nothing changes in a manner that seems to relate to your input, you suspect it is not listening to you.
Based just on this example I conjecture that we feel listened to when a system responds to our utterances and actions in a harmonious manner that honors our purposes. I further conjecture that the advice to maintain attentive silence in order to listen better is a special case of change in such a way as to foster harmony and supportiveness.
Can we think of a situation where listening to someone means shouting loudly over them? I can. I was recently in a situation where a quiet colleague was trying to get students to return to her tutorial after a break. The hallway was too noisy and few people could hear her. I noticed that, so I repeated her words very loudly that her students might hear. I would argue that I listened and responded harmoniously in support of her needs. I didn’t ask her if she felt that I listened to her. She knows I did. I could tell by her smile.
If my wife cries “brake!” when I’m driving, I hit the brake. The physical action of my foot on the brake is her evidence that I listened, not attentive silence or passivity.
It may be a small change or a large change, but for the person communicating with you to feel listened to, they must see good evidence of an appropriate change (or change process) in you.
Let me tell you about being a father of a strong-minded son. I have been in numerous arguments with my boy. I have learned how to get my point across: plant the idea, argue for a while, and then let go of it. I discovered it doesn’t matter if he seems to reject the idea. In fact, I’ve come to believe he cannot reject any idea of mine unless it is genuinely wrong for him. I know he’s listening because he argues with me. And if he gets upset, that means he must be taking it quite seriously. Then I wait. And I invariably see a response in the days that follow (I mean not a single instance of this not happening comes to mind right now).
One of the tragedies of fatherhood is that many fathers can’t tell when their children are listening because they need to see too specific a response too quickly. Some listening is a long process. I know that my son needs to chew on difficult ideas in order to process them. This is how to think about the listening process. True listening implies digestion and incubation. The mental metabolism is subtle, complicated, and absolutely vital.
Let People Chew on Your Ideas
Listening is not primarily about taking information into yourself, any more than eating is about taking food into yourself. With eating the real point is digestion. And for good listening you need to digest, too. Part of digestion is chewing, and for humans part of listening is reacting to the raw data for the purposes of testing understanding and contrasting the incoming data with other data they have. Listening well about any complicated thing requires testing. Does this apply to your spouse and children, too? Yes! But perhaps it applies differently to them than to a colleague at work, and certainly differently than testing-as-listening to politician or a telemarketer.
Why does this matter so much? Because if we uncritically accept ideas we risk falling prey to shallow agreement, which is the appearance of agreement despite an unrecognized deep disagreement. I don’t want to find out in the middle of a critical moment on a project that your definition of testing, or role, or collaboration, or curiosity doesn’t match mine. I want to have conversations about the meanings of words well before that. Therefore I test my understanding. Too many in the Agile culture seem to confuse a vacant smile with philosophical and practical comprehension. I was told recently that for an Agile tester, “collaboration” may be more important than testing skill. That is probably the stupidest thing I have heard all year. By “stupid” I mean willfully refusing to use one’s mind. I was talking to a smart man who would not use his smarts in that moment, because, by his argument, the better tester is the one who agrees to do anything for anyone, not the one who knows how to find important bugs quickly. In other words, any unskilled day laborer off the street, desperate for work, is apparently a better tester than me. Yeah… Right…
In addition to the idea digestion process, listening also has a critical social element. As I said above, whether or not you are listening is, practically speaking, always a matter of potential dispute. That’s the way of it. Listening practices and instances are all tied up in socially constructed rituals and heuristics. And these rituals are all about making ourselves open to reasonable change in response to each other. Listening is about the maintenance of social order as well as maintaining specific social relationships. This is the source of all that advice about listening by keeping attentively quiet while someone else speaks. What that misses is that the speaker also has a duty to perform in the social system. The speaker cannot blather on in ignorance or indifference to the idea processing practices of his audience. When I teach, I ask my students to interrupt me, and I strive to reward them for doing so. When I get up to speak, I know I must skillfully use visual materials, volume control, rhythm, and other rhetorical flourishes in order to package what I’m communicating into a more digestible form.
Unlike many teachers, I don’t interpret silence as listening. Silence is easy. If an activity can be done better and cheaper by a corpse or an inanimate object, I don’t consider it automatically worth doing as a living human.
I strongly disagree with Paul Klipp when he writes: “Then stop thinking about talking and pretend, if it’s not obvious to you yet, that the person who is talking is as good at thinking as you are. You may suddenly have a good idea, or you may have information that the person speaking doesn’t. That’s not a good enough reason to interrupt them when they are thinking.” Paul implies that interrupting a speaker is an expression of dominance or subversion. Yes, it can be, but it is not necessarily so, and I wish someone trained in Anthropology would avoid such an uncharitable oversimplification. Some interruptions are harmful and some are helpful. In fact, I would say that every social act is both harmful and helpful in some way. We must use our judgment to know what to say, how to say it and when. Stating favorite heuristics as if they were “best practices” is patronizing and unnecessary.
One Heuristic of Listening: Stop Talking
Where I agree with Paul and others like him is that one way of improving the harmony of communication and that feeling of being coherently and charitably responded to is to talk less. I’m more likely to use that in a situation where I’m dealing with someone whom I suspect is feeling weak, and whom I want to encourage to speak to me. However, another heuristic I use in that situation is to speak more. I do this when I want to create a rhetorical framework to help the person get his idea across. This has the side effect of taking pressure of someone who may not want to speak at all. I say this based on the vivid personal experience of my first date with the one who would become my wife. I estimate I spoke many thousands of words that evening. She said about a dozen. I found out later that’s just what she was looking for. How do I know? After two dates we got married. We’ve been married 23 years, so far. I also have many vivid experiences of difficult conversations that required me to sit next to her in silence for as long as 10 minutes until she was ready to speak. Both the “talk more” and “talk less” heuristics are useful for having a conversation.
What does this have to do with testing?
My view of listening can be annoying to people for exactly the same reason that testing is annoying to people. A developer may want me to accept his product without “judgment.” Sorry, man. That is not the tester’s way. A tester who doesn’t subject your product to criticism is, in fact, not taking it seriously. You should not feel honored by that, but rather insulted. Testing is how I honor strong, good products. And arguing with you may be how I honor your ideas.
Listening, I claim, is itself a testing process. It must be, because testing is how we come to comprehend anything deeply. Testing is a practice that enables deep learning and deeply trusting what we know.
Are You Listening to Me?
Then feel free to respond. Even if you disagree, you could well have been listening. I might be able to tell from your response, if that matters to you.
If you want to challenge this post, try reading it carefully… I will understand if you skip parts, or see one thing and want to argue with that. Go ahead. That might be okay. If I feel that there is critical information that you are missing, I will suggest that you read the post again. I don’t require that people read or listen to me thoroughly before responding. I ask only that you make a reasonable and charitable effort to make sense of this.
"Hmmm ..." answered Marco,
"It may be you're right.
I've been here three hours
Without one single bite.
There might be no fish ... "... But again,
Well, there might!" "Cause you never can tell
What goes on down below! "This pool might be bigger
Than you or I know!"Testers, I give you McElligot's Rule*: when you're chasing a might on the basis of a never-can-tell, it's worth putting your rod aside now and again to think about what you're tying to achieve, how, why and for who.
* OK, heuristic, but we're rhyming today.
- Material about constrained versus unconstrained isolation frameworks : specifically those that can fake things like statics and priavte methods.
- A new chapter 6 on what makes for a good isolation framework and how frameworks like Typemock work under the covers.
- I no longer use RhinoMocks. Stay away from it. It is dead. At least for now. I use NSubstitute for examples of Isolation Framework Basics, and I also highly recommend FakeItEasy. I am still not crazy about MOQ, for reasons detailed in chapter 6.
- I added more techniques to the chapter about implementing unit testing at the organizational level, such as understanding influence factors
- There are plenty of design changes in the code I show in the book:
- Mostly I stopped using property setters and am mostly using constructor injection.
- Some discussion of SOLID principles is added, but just enough to make it whet your appetite on the subject.
- The build related sections of chapter 7 also contain new information. I learned a lot since the first book about build automation and patterns. It’s the topic of my next book. In this book I talk about build pipelines and where unit testing fits in the process.
- I recommend against setup methods, and give alternative ideas on getting the same functionality out of your tests.
- I also use newer versions of Nunit so some of the newer Nunit APIs changed in the book( Assert.thorws. vs Assert.Catch, TestCase attributes and more)
- In chapter 10, the tools relating to legacy code were updated.
- Having worked with Ruby for the past three years along side .NET, I gained more perspective about design and testability arguments, reflected in chapter 11, dedicated only to this topic.
- The tools and frameworks appendix was updated with new tools, and old tools were removed.
Also, here is a talk I did about it:
A Second Look at Unit Testing by Roy Osherove from Roy Osherove
There are plenty of options when it comes to choosing your suite of testing tools. Some tools may excel at one specific task, while others perform at an average level for more than one testing task.
A few months ago, we launched the Tool Reviews section of our site to let members of the uTest community rate and review the best testing tools. The community has responded by easily singling out the most popular and highest rated testing tools.
Over at uTest University, we’ve recently published new tutorials for some of the most requested tools in order to help testers set up these tools to use for testing. These tutorials are designed to be quick, easy to follow, and to get you up-and-running in no time.
Check My Links is a browser extension developed primarily for web designers, developers and content editors. The extension quickly finds all the links on a web page, and checks each one for you. It highlights which ones are valid and which ones are broken. You can learn how to set up and use Check My Links for testing using this new tutorial.
Mobizen is a tool that allows the mirroring and control of an Android device using your computer. This free tool features the ability to connect to the device using USB/Wifi/mobile network, screen mirroring with a high frame rate, and movie recording and capturing screenshots. Learn how to set up and use Mobizen for testing using this new tutorial.
liteCam HD is a computer screen recorder for Windows users that helps create professional-looking HD videos. This tool’s easy interface makes quick recordings and reduces complex settings. Learn how to set up and use liteCam HD for testing using this new tutorial.
uTest University is free for all members of the uTest Community. We are constantly adding to our course catalog to keep you educated on the latest topics and trends. Have an idea for a new course or how-to tutorial? Submit your course idea today.
I gave several training courses on being a Tech Lead and found myself giving a number of book recommendations. Although books are no substitute for experiential learning and close feedback cycles, they are useful as ways of introducing some key skills developers rarely practice in their day-to-day tasks.Negotiation
A Tech Lead represents both the technical perspective to outside stakeholders, and often carries a business perspective back into the technical team. Conflict is inevitable and understanding how to negotiate to an optimal solution for two parties is a timeless skill.
Getting to Yes was one of my favourite books. It’s short and insightful. The book describes the different between Positional-based negotiation (typical) vs Interest-based negotiation.
Meetings. Meetings. Meetings. Three dreaded words that a developer doesn’t want and often can avoid. A Tech Lead often dreads the numerous meetings as well, but will be often expected to contribute. Most meetings will be poorly planned and facilitated, leading to even more drawn-out meetings. In my experience, when done well, meetings can be focused, short and fruitful when they are well-facilitated. Facilitation skills are also useful on a day-to-day basis when ad hoc meetings between team members occur, or when a particular topic needs to be discussed.
The more collaborative a team becomes, the more useful facilitation skills are to the Tech Lead as they blur into the background to all voices be heard.
The Skilled Facilitator (Schwartz) is the first book I recommend to new facilitators. I find the book easy to read and is comprehensive in its explanation about the role of the facilitator.
Facilitator’s Guide to Participatory Decision-Making (Kaner) is a more focused book, covering how to have group discussions, balance hearing all views and to converge into the best outcome.
Collaboration Explained (Tabaka) is written by an agile practitioner who I trust dearly. I have see her facilitate, and her wisdom is captured in this book that will be highly relevant to particularly agile teams.
With authority comes responsibility and the Tech Lead suddenly sees risks everywhere. Or worse, they don’t see any risks at all.
Waltzing with Bears (De Marco and Lister) is the timeless book that talks about risk management in the settings of software development. Although some of the examples may feel a bit outdated (death march projects), our industry still has plenty of them and the lessons are still relevant for today’s style of software development.
Unsurprisingly the book recommendations above are not only relevant to Tech Leads, but to anyone who may find themselves in a leadership role. There are plenty more skills and books to recommend, but these are a good starting set.
Thanks to those of you who joined us for our last webinar, How Yahoo! Mail Transformed Its Functional Testing + Continuous Delivery Process with Front End Developer Neil Manvar.
Over the last two years, Neil’s most important contribution to Yahoo! has been developing a modern functional testing framework that is based on open-source technologies, plays well with legacy code, supports many browsers, does not need maintenance, is readable to product managers, and makes writing a pleasure.
In his quest to build this framework, he’s also learned to navigate structural and organizational challenges; most significantly convincing upper management to require each developer to write and run tests on their code as their new standard operating procedure.
Missed the webinar or just want to hear it again? You can listen to the recording HERE, or check out the slides below.
How Yahoo! Mail Transformed Its Functional Testing and Continuous Delivery Process from Sauce Labs
Predictive analytics have proven themselves to be an invaluable resource for countless organizations in many fields. By leveraging this technology, firms can gain better insight that leads to improved decision-making and, consequently, superior results.
The most recent example of the power of predictive analytics surrounds health care. Massachusetts General Hospital now utilizes this technology to make better clinical decisions, leading to more efficient and effective patient care.
MGH is widely acknowledged as one of the nation's leading centers for health care. Frequently, patients are referred to the hospital by doctors who simply don't have the means or experience to effectively treat these individuals themselves. This means that MGH surgeons and clinicians frequently face some of the most challenging, high-risk health care challenges out there.
Speaking to HealthITAnalytics, Dr. David Ting, associate medical director for information systems at the Massachusetts General Physicians Organization, explained that the organization now applies predictive analytics technology to its Queriable Patient Interface Dossier in order to better assess individual patients' risks.
Previously, according to Ting, MGH surgeons would have limited insight into the risks involved in a given operation. They would typically work with referred patients, and therefore did not have a robust, one-on-one experience with those individuals.
"How do you know whether something's appropriate or not when this is a patient that comes to you and you have 15 minutes to go through the chart or talk to the patient?" said Ting, the news source reported. "Well, that's how we use QPID."
The doctor went on to explain that the QPID system delivers insight into the surgical risks of a particular procedure when performed on a patient with a specific set of circumstances and conditions. The system takes into account the entirety of a patient's electronic health record, delivering comprehensive predictive insight concerning the risks of the intended operation.
"The system automates those searches using national guidelines, and then it essentially shows the results in a dashboard with a red, yellow or green risk indicator for the surgeon or proceduralist to see," Ting said, according to HealthITAnalytics.
He went on to note that surgeons can then have much more informed, productive conversations with patients. Rather than relying on guesswork or general trends – for example, the average percentage of people who experience complications from an operation – doctors can offer data-based evidence that a particular procedure has a high risk for a specific patient, based on his or her unique history, and that an alternative approach may be the better option.
Not only does this help to cut down on unwise surgical procedures, but it also empowers patients to make more informed decisions in regard to their own treatment.
In order for this and other health care-related predictive analytics to yield positive results, though, hospitals and other care providers must overcome a number of hurdles. One of the most significant of these is the need to fully integrate with EHR systems. The MGH predictive analytics solution relies entirely on EHRs to accurately gauge the risk for an individual patient, as opposed to the average dangers posed by the operation. The same will likely be true of any organization's health care predictive analytics efforts.
Additionally, care providers must utilize high-quality algorithms to ensure the effectiveness of their predictive analytics systems. Without embeddable, high-performance algorithms that integrate with all relevant apps, organizations are unlikely to optimize the accuracy or usability of their predictive analytics tools. For a health care provider, such shortcomings may not only be frustrating, but actually dangerous.
We live and breathe code coverage and the pursuit of building quality code. Since we have been doing it for years, we forget that each and every day new people discover and are getting started with .NET code coverage.
With that in mind, we thought it would be helpful to pull together some of the most common questions we receive about code coverage and NCover. Here they are:
What is Code Coverage and Why Does It Matter?
In a nutshell, code coverage is the process of determining which sections of your source code have been tested and which sections of your source code have not been tested. This insight allows you to improve your overall testing strategies and the overall health of your code base. The ultimate golas for most organizations are (1) to increase revenue by providing end users with a higher quality application that is easier to sell and (2) to reduce the total costs of supporting that application in terms of general support and bug fixes. Looking for more Code Coverage 101? We’ve got you covered here.
Can I Collect Code Coverage on My Build Server?
Collecting code coverage on your build service is available through our server-based product, Code Central. It allows you to monitor any number of build servers and test machines and collect coverage data. Code Central can collect coverage directly if it is installed locally on the build server or it can connect to any machine with Collector installed and collect coverage remotely.
Now that you know you can – the next question is HOW? Well – we’ve got that spelled out for you in three easy steps right here.
Can I Cover IIS and My .NET Web Apps?
Yes you can! NCover collects coverage on your .NET web apps by profiling IIS. Specifically, NCover watches the w3wp.exe, the IIS worker process, in order to collect coverage. This approach allows you to automatically capture coverage once you have properly configured your project. How do I properly configure my project? Well we’ve got that for you right here.
Did we miss your question? Leave us a comment or check out our support and resources sections to help find the answers you are looking for. Keep covered and code on our friends. We cannot wait to see what you make next.
Our community is made up of 150,000+ testers in 200 countries around the world, the largest of its kind, and our testers have already stretched the definition of what testing ‘in the wild’ can be, by testing countless customers’ apps on their own devices where they live, work and play.
That ‘play’ part of In-the-Wild testing is primed to take up a much larger slice of testers’ time. While we have already seen a taste of it with emerging technologies gradually being introduced into the mobile app mix, there are four major players primed to go mainstream in just a couple of short years. That means you can expect testers to be spending less time pushing buttons testing on mobile apps in their homes and offices…and more time ‘testing’ by jogging and buying socks. Here’s why.Apple Pay
Google Wallet has been out for several years now, but it is widely expected by many (including this guy) that Apple Pay will be the technology that takes mobile payments to the mainstream with its ease-of-use and multiple layers of security.
Of course, it will take more of the little banks and retailers to be on-board for Apple Pay to spread like wildfire, but Apple is banking on an ‘if you build it, they will come’ strategy, and it already seems to be working. Case in point: My little, local credit union in Massachusetts — probably 1/25th the size of a Chase or Citibank — has already previewed that it’s working with Apple to bring Apple Pay to all of its members.
This is all well for consumers, but it provides even more of an opportunity for testers — there will be plenty of retailers lined up to make sure the functionality works with their environments, along with retailers needing testers to verify that any in-app functionality is sound when consumers use Apple Pay from the comfort of their own homes. Expect a lot of testers buying socks and sandwiches (not together in the same transaction) as part of their new “testing” routine in the coming months and years.Smartwatches
While I have been in the camp of only wanting a smartwatch if it promises to produce lasers, I know that there are many out there that will be early adopters. And who can resist their stylin’ nature?
Once again, Apple in this technology category has made smartwatches sleek and sexy with a variety of styles and accompanying straps on its soon-to-be-released Apple Watch. While the $349 may be a sticker shock to many, one space that it is expected to take off in is the enterprise amongst executives and employees on the go.
And for testers, smartwatches will open up a whole new era and class of apps more pint-sized than ever…that you can bet will need lots of testing on proper screen rendering and functionality in those board meetings filled with execs.Health & Fitness Wearables
With Google and Apple taking on this realm in its smartphones, and fitness-centric trackers from Nike, Fitbit and Jawbone in the form of armbands, the health and fitness wearable market is one that has already actively had much adoption.
From a tester standpoint, testing fitness devices may be the most ‘out there’ definition of in-the-wild testing. As health and fitness apps and armbands track fitness- and health-specific information such as number of steps taken, heart rate and calories burned, expect a lot more of testers’ routines including a 2-mile jog lumped in with their mobile testing.Automobile In-dash Entertainment
From popular car manufacturers from Ford and Toyota to BMW and Audi, to navigation services like TomTom and Garmin, in-dash entertainment and navigation systems have already taken off in the past year, and that trend is only expected to continue as these packages eventually become standard in automobiles.
And this only opens up more doors for testers. We’ve all heard of texting while driving, but did law enforcement consider ‘testing’ while driving? Testing teams should consider safety first and buddy-up their testers when sending them out to drive for a “testing” assignment.
What do you think? Is the tester’s work environment going to be stretched even more into the wild in the next few years because of these emerging technologies? Are there others you would add to the list such as Google Glass? Will these technologies still just be a shadow in a tester’s daily testing routine? Let us know in the Comments now.
In my last post I introduced the async and await keywords and I showed you what the C# compiler generates from an async method. In this post we will see what the PurePath looks like when we use an async API in our code. Feel free to follow my steps by downloading the free trial […]
The post The Performance Impact of Async – Looking at the PurePath appeared first on Dynatrace APM Blog.
Upgrading to Mac OS X Yosemite (10.10) may impact your Seapine product installation. There are a couple of issues to be aware of:
- If you use Surround SCM PostgreSQL databases, the Surround SCM Server will not be able to connect to the databases after upgrading Mac OS X. During the upgrade, Mac OS X automatically deletes empty PostgreSQL folders that are required for the PostgreSQL server to run correctly. It’s easy to fix this issue. See this knowledgebase article.
- If you use TestTrack Web, TestTrack Web Server Admin, SoloSubmit, or Seapine License Server Web Admin, users will not be able to log in to the clients after upgrading Mac OS X on the computer hosting the TestTrack Server or Seapine License Server. Mac OS X 10.10 uses Apache 2.4 and the required mod_cgi module is not enabled by default in this version. This one is easy to fix too. See this knowledgebase article.
We haven’t seen any impact on the TestTrack or Surround SCM Clients after upgrading to Mac OS X.
If you have any questions or need help, please contact Seapine Support.Share on Technorati . del.icio.us . Digg . Reddit . Slashdot . Facebook . StumbleUpon