What does your network do to your customer experience? Without a smooth experience, your customers will abandon purchases and shop elsewhere.
Keep reading to find out how to give them the experience they expect.
Dynatrace in Leaders Quadrant of 2015 Gartner Magic Quadrant for Application Performance Monitoring (APM)
Here we are again, 405 days from last year’s Gartner Magic Quadrant for APM and we are proud and humbled to be in the Leader’s quadrant for the sixth consecutive year*. We’ve had an amazing and transformational year, and we are excited to see that our passion and undivided focus on the APM segment resulted in […]
If you have seen a PurePath of your application you – like many others — were likely blown away with the diagnostics information captured: Full end-to-end method level tracing and diagnostics, from the Browser, through your application stack, all the way down to SQL. Also, performance, scalability and functional hotspot detection attained by simply installing a single library on […]
The post Full Stack Diagnostics – Full Mac Support – Dynatrace Personal 2016! appeared first on Dynatrace APM Blog.
I’m sitting here thinking about my career over the last decade or so, thinking about how things once were, and how things have changed. One thing stands out to me: how much faster things are now. How fast we build, how fast we release, how quickly we have to test, how quickly we have to write. How do we balance documentation (which, let’s face it, could take a lot of time) with the need to get things out the door? How do we keep up in the continuous pipeline? It comes down to having a centralized strategy that consists of best practices, how to get through your day-to-day work, and working as a team to know what needs to be tested.One Strategy to Rule Them All
One thing I’ve found that has helped to save time is to have a centralized space to reference when nothing really changes in HOW things need to be tested. These are things that do not change across projects or releases and should be considered as long-term and used as a reference. We used to do this for each epic and it drove me nuts — it ultimately led to tons of strategies with duplicate information throughout. Now, we have a reference wiki space and go over strategies that everyone (not just QA) should be familiar with. These strategies should also be a part of passing acceptance criteria, and your engineers need to know these strategies as well.
Here is a sample of what we have focused on as the general strategy does not change frequently, and things to consider when defining it:Rest API Testing StrategyAre your teams creating tests strategies for any API they write? Is the entire team familiar with how they should be tested? Is every method and parameter getting a test? Mobile and Responsive Testing StrategyDo you need to test in a native mobile browser? Which devices? How will you approach that? Are your teams designing and building for various breakpoints? Exploratory Testing StrategyWhen and how do you perform exploratory testing? Who does it? How do you define the charters? Where do they live? Browser Testing StrategyDo you explicitly support particular browsers? How do you test them? Where to Test (Environments)Is your team clear on where things need to be tested? What types of testing are done in integration, development, staging and production? How do you access the servers? From Feature to TestDoes your team know what is expected to happen once a feature is assigned? How do you start determining what to test? How are you expected to track the work, and when do you handle certain aspects of QA? Non-Functional Requirements Testing StrategyHow will your teams handle testing for accessibility, localization, performance and security? Will it belong to external teams? Product CheckpointsThese may be less to do with industry-wide testing, but more applicable to your specific product. This could range from upgrade and version support to client data, but it is important to understand what the team should think about when building a feature. Test Automation StrategyAre all teams on the same page as far as the tools available, best practices, etc? Defect Tracking StrategyIs everyone clear on how to report a bug if one is found? What information is required? It makes life so much easier when people enter tickets uniformly.
Having a centralized space handy and only explicitly calling out when things change saves time towards your continuous delivery model. To track the work, we use checklists embedded in our stories for definition of done and acceptance criteria, and we cannot close the story until they are considered complete. Instead of having to write a separate strategy for each of these common practices, we now simply reference them and ensure they are done.Smaller Stories, Smaller Tests
Of course you will have to write tests with the feature you are building, but one thing I have seen evolve over time is the size of the specification. Ten years ago this could have been 50+ pages defining the entire feature. Trying to digest that and create a test plan took forever, and usually generated more questions because it was a very Waterfall world, and the team was just handed the specs.
Times change. Now, we are looking at extremely small stories, which helps us focus on what needs to be tested. As your team defines acceptance criteria together, it is easier (and faster) to design your tests on a small piece of functionality vs. the entirety of the feature. I’ve seen my tests plans dwindle from long-winded documents to very short tables of Given/When/Then statements that I can complete in a few hours. When we are in a world of Test Driven Development, I think we’ll see even less documentation as those tests become the driver of the code.
We also recognize that our goal is to automate as much as we can (as makes sense). What we initially define is not a living, breathing document. It often serves as just enough to get through a sprint and get QA, ENG and Design on the same page, but is not maintained throughout the life of the product. If there is a change, we simply write a new manual test or edit the existing automated script as part of the change request or story.The Need for Speed
The need for everything to become even faster is not going away in the Continuous world. How do YOU balance writing tests and getting things delivered in a constantly shortened timeline?
Ashley Hunsberger is a Quality Architect at Blackboard, Inc. and co-founder of Quality Element. She’s passionate about making an impact in education and loves coaching team members in product and client-focused quality practices. Most recently, she has focused on test strategy implementation and training, development process efficiencies, and preaching Test Driven Development to anyone that will listen. In her downtime, she loves to travel, read, quilt, hike, and spend time with her family.
3 days in London: Getting the latest in Performance Engineering, DevOps and Lifecycle Virtualization
What a week at HP Discover 2015 London! If you were not able to make it (or even if you were) and want the highlights for Performance Engineering and Performance Lifecycle Virtualization, check out this blog for the key items you need to know about.
But this one, this double centenary, this one is short and sweet and about ideas.
My blog, I see more and more, is a repository of ideas I've had, and sometimes about aspects of the ideas, meta ideas such as the paths to those ideas, connections between ideas and the way that ideas breed ideas.
I try hard not to knowingly regurgitate other people's ideas unless I am commenting on them, or questioning them, or testing my own against them.
Which doesn't mean that I don't value them. Quite the opposite in fact: I am a fan of ideas, for and by us all; not least because with no ideas there are no good ideas.
Image: Old Book Illustrations
Is your development process balanced? Are you meeting the needs of your engineering, software development, quality assurance (QA), and regulatory teams? If so, you’re ahead of 90% of the medical device development industry.
As we reported in State of Medical Device Development 2015, very few respondents found this balance easy to achieve. Out of more than 900 respondents, less than 10% met the business needs of all groups without difficulty.How difficult is it to balance the business needs of Engineering, Software Development, QA, and Regulatory?
When a company is out of balance, they either lose the ability to innovate or experience a decrease in quality, depending on which team has more weight.
If you lean too far toward regulatory, for example, you become so focused on regulations that you’re hesitant to explore greater communication or development efficiencies. Innovation takes a nosedive.
If a company puts too much emphasis the software development side, quality may slide. Risk goes up.Many Moving Parts
One of the reasons it’s so difficult to achieve balance is because the development process has a lot of moving parts. When you add regulatory compliance into the mix, it adds a whole new level of complexity.
We asked our survey respondents to name their most difficult areas to balance, and they identified delivery expectations, verification and validation (V&V), and documentation as the top three.What are the three most difficult areas to balance in the development process?
When you look at the graph above, you can see that most of these categories can be broken down further, adding even more elements that need to be monitored, managed, and traced.Is Balance Even Possible?
Is it possible to balance all of these spinning plates? That is, can you strike a balance that meets your business goals? The short answer is, “Yes.”
The longer answer is, “Yes, but it takes a some work—and possibly some additional tools—to get there.”
Many companies adopt tools to help foster communication between the core teams involved in product development—engineering, software development, QA, and regulatory. Improved communication is a good starting point, but to satisfy the unique needs of these groups, it’s important to understand their key desires and goals.Where Do You Begin?
Our white paper, Balancing the Product Development Process: 3 Functional Areas to Consider, is a good starting point. It takes a look at how balancing these core functional areas will help lower production costs and get products to market faster, while maintaining a high degree of product quality.
In addition to examining these areas, the paper also offers tips for striking a balance between them, including:
- Find the existing similarities between the groups.
- Evaluate what works and what doesn’t.
- Meet with each team lead individually to discuss how their team works.
- Find a neutral party to arbitrate the discussions to overcome internal politics.
- Create an action plan after reaching a consensus.
Despite the survey results, balance can be achieved. The fact that so many respondents struggle with the issue of balance can be good news for you.
If you can achieve what your competitors can’t, you’ll gain distinct advantages. Balancing these key functional areas will help you improve development speed, foster greater collaboration, and respond more nimbly to change.
We’ve recently updated the QA Wizard Pro Best Practices with lots of information you can use to avoid common mistakes and improve the quality of your automated functional and regression tests. Regardless if you are a new or experienced user, implementing these practices helps ensure you are using QA Wizard Pro most efficiently. So, why not take a few minutes to check them out?
And remember, the very best practice of them all is to complete our QA Wizard Pro user training course. We even offer customized training, which can help you create a unique solution for your specific automated testing needs. Learn more about our available training options.
Thank you for your participation in our Customer Experience Survey. We sincerely appreciate your valuable contribution and interest in helping us to improve. We are currently analyzing the answers and will publish the results of the survey as soon as possible.
The main goal of this short survey is to gather detailed information on how you use Ranorex. We would like to know your opinion on our software, so that we can make the Ranorex tools even better.
The first 50 participants will earn a free Ranorex Certification Exam and will be contacted soon.
You can rest assured that the information you submit will be kept confidential.
IBM WebSphere Commerce is robust and highly scalable. But you know the work is just beginning once your platform is in place, right? From the outset, you need to work to ensure application performance. Satisfying today’s demanding shoppers, who demand flawless experience across smartphones, tablets and PCs, requires you to relentlessly fine-tune and evolve your […]
The post Application Performance & 4 Key Tips for Optimizing Your IBM WebSphere Commerce Site appeared first on Dynatrace APM Blog.
We believe that since LoadRunner was released in August 2015, you have upgraded to our latest LoadRunner version (12.50).
However, in case you “haven’t got around to doing it yet” in practice :) , and have a gut feeling that upgrading to a new version might be a tedious process, we have collected a few tips & tricks to help you out while upgrading your existing LoadRunner release to the newest one available.
This guide presents you with the best practices recommended by HPE R&D for a smooth upgrade of HPE LoadRunner, and articulates what needs to be taken into consideration during the upgrade process .
This will shorten the process and answer many of those questions that might be buzzing around your head.
The tips & tricks were written especially for you, the Performance Engineer, to help you gain the latest and greatest LoadRunner added functionalities!
So act right now!
You are presented with a problem. You are a problem-solver but you know that diving into the detail of potential solutions is only one way to skin a cat (although the problem is rarely about feline furectomies in my experience). So you think about asking questions that help you to understand the problem. You might ask questions that help to constrain your search for solutions to the problem. You might ask questions that help to understand the history of the problem, the needs and intent of the problem-poser, the permitted ways in which a solution can be found, the scope of the solution, the time-frame for the solution, the priority of the solution, the necessity of the solution. You learn about the problem. And then you solve it, or not, as required. Well done you, too!
The kinds of questions just listed are meta questions - questions that assist with an underlying question. I look out for meta questions because they show that the person asking them is, amongst other things, capable of maintaining a view of the problem itself and the way in which the problem is being or might be approached. This kind of person is giving themselves a chance of generalising across problems, of reducing the solution space, of understanding that the problem need not be addressed or perhaps would be better framed in some other way.
Of course, having the capacity to think of meta questions doesn't tell you how and when and where to ask them to avoid aggravating the solution-seeking poser. That's a different problem.
On December 15, the Toulouse JAM was co-hosted with the Toulouse JUG and Toulouse DevOps. Indeed it made sense since Jenkins is written in Java, makes use of Groovy code in many places (system groovy script, job dsl, workflow...), and it also made sense to co-organize with the local DevOps community since Jenkins is also a great tool to enable Continuous Integration, Continuous Delivery and automation in general. There were 103 RSVPs, with 80 to 90 people in attendance.
There were 3 talks planned for the evening:
- Job DSL Intro [fr], by Ghislain Mahieux
- Workflow plugin [fr], by Michaël Pailloncy (co-maintainer of the Build Trigger Badge plugin)
- Feedback on almost 10 years of CI and what's upcoming [fr], demo with Jenkins build scaling with Docker Swarm, by Baptiste Mathus
Note: presentations have been recorded (in french). They are still being processed, and once they are posted we will update this blog.
My off hours hobby is music production.
Here are similarities I see between coding and music production so far:
- Code compiles into binary - midi is rendered into wav files
- When producing music you need to take many breaks to get your ears “out of the mix” and get your head clear again. The same goes for coding when facing tough creative problems or complicated code.
- Software culture is moving in the direction of automation and factories, with architectures that support changing things on the fly. Music production has two opposing factions: a. Newer pop songs are made almost in an industrial fashion (try many tracks in a day, find one that works , then lyrics and vocals are found for it from many contenders; and b. singer-songwriter which is all about manually crafting a song which can take a lot of time. (compare that to a hand crafted optimized piece of code that needs to run at a very low level like a DSP unit or real time calculations)
- Pair-Programming - > most new music these days is not done alone: there are lyric writing teams, melodic writing teams, production teams.
- in Music, new digital tooling is taking the place of older generation analog tooling. Instead of filling rooms with huge hardware, people use digital work stations with software plugins that emulates almost every piece of hardware out there. Software coding is fully digital, but used to be very hardware oriented . Software testing is still very manual but automation is starting to take its place.
- Long term support: Software can keep changing after you’ve released it (new features added etc. Music is usually delivered in multiple different versions: radio mix, PG safe mix, club mix etc.. and music also gets remixed, new covers by other bands are made, remakes by the original band in shows, digitally remastered albums… not exactly the same, but in music all the “stems” (the parts that make the individual atoms of the song) are always saved and can be used to recreate different variations of the song.
- Code has classes and functions, Music production (digital) also has building blocks: Sound designers use waveforms and combine them, munge them up and process them to create new types of sounds that are then reused by other musicians. If a waveform is the input of code, an LFO envelope is a type of function that operates on that code. Those are just two types of the :atoms” of synthesized music)
- When mixing, it is encouraged to take many breaks (20 minutes mixing, 15 minutes break) so that your ears don’t get too used to the mix. Programming is also a very tough activity that is helped by taking many small breaks.
- TDD: In music you might have a “reference” mix - a song you like or a sound you want to sound like that tells you how close you are to getting the same results (loudness, frequencies, etc). TDD is the same way somewhat in that you set yourself a target and see if you measure up to it or not. Music is not automated for this though, and is not a any kind of regression test.
- Music pros do as much integration testing as possible they make their friends, DJS, their mom and their cat hear the mix all the time because they know they are not objective about how it translates in the real world.
- There’s more but my head is drawn a blank..
In our last update we mentioned there will be 2 Selenium Confs in 2016 — one in India, another somewhere else (TBD).
Well, we are pleased to announce the official dates and location for Selenium Conf India!
When: June 24th & 25th, 2016
Where: Bangalore, India (at The Chancery Pavilion Hotel)
Mark you calendars! We’ll have more details as they become available (e.g., call for speakers, ticket sales, etc.). To get the latest updates, be sure to sign up for the Selenium Conf mailing list.