Archives for October 2020

Pair programming at Codacy and why we do it

October 30, 2020 by Fiona Nic Dhonnacha

Pair programming, also known as pairing or “dynamic duo” model is not a new concept, and it was pioneered by C/C++ guru P.J. Plauger (Scott W. Ambler, Larry Constantine, 2001). This practice consists of two developers working together off of a single screen: one is the driver, who actively codes, whereas the other, the navigator, provides instant feedback.
Once teams focus on making pair programming work and get the dynamics right, they can reap multiple benefits from it.

In this post, we will uncover how all of our Product teams gathered to brainstorm about this technique and the advantages we came up with. It is important to address here, that pairing isn’t necessarily a concept exclusive to developers; anyone can pair, whether you’re in HR, Finance or Marketing, and right now, as remote work is more embedded than ever in our society, this is probably the best time to try it out.

We already had some development teams experimenting with pairing in the past and, as we went fully remote over two months ago, we thought that this concept made even more sense for others to try it out. Acknowledging its strong reputation, we wanted to encourage all the teams in Engineering to also experiment and adopt pairing, and eventually scale it to other departments. At the end of the day, this could be an opportunity for people to keep a connection with each other while working away from the office.

Facing the current “work from home” scenario, we decided then to join teams virtually, starting with the different development teams. Through a workshop format and breakout rooms with random groups of four or five people, we had everyone collaborating, sharing experiences and knowledge around Pairing.

As an outcome, we uncovered some of the benefits of this technique, why we should adopt it, and what makes it work. This was turned into a chapter in our handbook for everyone to refer to when pairing and to serve as a basis for every pairing experience at Codacy, whether in person or remotely.

The positives of pair programming

We improve knowledge sharing, effectively helping each other grow
We are able to shorten the learning period of our codebase and therefore improve the onboarding.
We decrease the bus factor
By constantly working side by side, and being able to proceed with work if one person is unable to work on a given day, this makes us much more resilient as squads and as a company; over time it will be easier to have each other’s backs whenever needed.
We make our reviews easier and simpler
When we pair, we’re discussing and getting real-time feedback on the work that we’re doing. This helps to improve the quality and speed of delivery because we find issues sooner rather than when we request a review.
We work in a more focused way
We already knew reducing the amount of Work in Process (WIP) makes us go faster and be more efficient. When we pair, there are fewer streams of work open in parallel. That means we’re more focused on delivering the most prioritized features and can maintain the workflow.
We deliver better work when we do it together
We’re excited about having cross-functional teams that can deliver a feature from start to finish. Pairing allows us to not just learn from each other, but also to increase the discipline of our practice, and do the right thing together.
We get much faster feedback
With pairing, we’re able to shift left and bring quality sooner rather than later. This brings much higher quality upfront, avoids making mistakes and later fixes, therefore also improving our speed.
We increase out teamwork levels
We go back and forth trying to solve a problem together, which increases empathy levels and improves relationships. This leads to a better understanding of each other, creating cool and fun dynamics between people in the squad.
Especially when pairing remotely, there’s a higher sense of productivity since we’re helping each other move forward with the challenge at hand.
We become better synched
Since we’re rotating pairs and we’re tackling things together, we inherently become more in sync with each other. Chances of being blocked are reduced and the overall alignment is better.

With the benefits listed, the next step was to understand how we would make it work and get the most out of it, considering the challenges that may arise.

There are a lot of behaviors and practices that contribute to a great pairing experience and that boost the quality and resilience of our squads.

What contributes to a great experience

It’s important to define the roles
It’s useful to have a pre-agreed set of guidelines on the pairing roles: Driver & Navigator. This helps in having a better understanding of the duties of each member, reducing friction and discussions whilst helping to focus on the challenge to be solved.
Communicate constantly and use clear, visual language
Thinking out loud, constantly speaking your thoughts, whether you’re the driver or the navigator, creates a guiding line for the reasoning of the pair and the work being done. It also helps you catch loopholes on your internal reasoning.
Remote preparations
It’s important that you’ve got silent conditions and a good microphone (make sure you test it). Remember that someone else is going to be looking at your screen, so adjust the resolution or font size in order for the other person to see well.
Visual cues are incredibly important, so make sure cameras are on and you can see each other while screen sharing. Try to keep the distractions for both people at a minimum.
Pairing dynamics
Before starting the pairing session make sure you’re both aware of each other’s schedules. Agree on a time for breaks, and respect those agreements.
To avoid getting distracted or creating an uneven dynamic, rotate frequently between the driver and the navigator. Set a timer to trigger a rotation at least every 30 minutes. Base your rotation on time, not completion of a task (to prevent never rotating).
Be collaborative
It’s really important to be open for some collaboration, accepting that there are going to be fewer parallel streams of work and a sense of speed decrease. The benefits outweigh these, so keep them in mind because you’ll be triggering feedback earlier and avoid possible rewrites of code.
Boost knowledge sharing
Pairing is an opportunity to help someone become a better professional and also to grow by learning from someone else. This openness to learn and teach is crucial for the pairing dynamic to work.
It’s also important to note that, in case someone knows way more than its pair, the person with the least knowledge should be encouraged to assume the driver role for longer.
Keep your mind open for all ideas
We all have different opinions. If we feel they are listened to and taken into account, we’ll be more willing to reach a compromise.
Rotate pairs frequently (e.g. twice a week)
Schedule the rotation of the elements of each pair. Make it dependent on time, not on task. If you’re halfway through a task when you’re supposed to rotate, simply choose which member of the pair continues working on it with their new pair colleague. This will also help to boost knowledge sharing and resilience in your squad.
Constantly improve, and share key learnings with the team
Focus on improving pairing over time. Have debrief moments after each pairing session, understanding what can happen to make it a better experience next time. Sharing this helps to build trust in each other and to create better dynamics.
Align work with your squad
It’s relevant to communicate beforehand which tasks will benefit most from pairing and when each person is available for pairing. Use refinements to signal which tasks must be tackled in a pair.
If things go wrong
Ask someone else’s help to ease any conflict that might have occurred. Remember that each person has different needs, personality and working styles, so it’s normal that you need some time, practice, trust and love in order to make the pairing work.

In this session, we fostered a moment where our squads shared their experience and lessons learned with each other, giving us the ability to understand more notably the advantages of pairing. This allowed everyone to increase their ability to pair, or at least encourage them to do it more regularly, knowing they have these guidelines as help, and more importantly, the rest of the organization supporting them.

At the end of the day, by engaging with this technique, development teams can avoid later fixes, reduce bugs, consequently improve speed, and cut the overall cost of programming. We’re already seeing some of these, and as an example, in the last few weeks, we reduced massively the number of new bugs, seeing up to a 75% reduction. Of course, this can be attributed to other factors as well, still, some of the results obtained after we started pairing have been remarkable.

In addition, pairing empowers our team members to grow in a shorter time span while contributing to social interactions. This also contributes to increasing the resiliency and knowledge of our teams and organization: when you pair, you are learning from, discovering with, or teaching someone else.

Having all of our different engineering teams embracing this technique was an achievement and the feedback is very positive. It also impacted our company culture, so much so that our next goal is having all of the other departments in the organization also trying it out, by following these insights we just shared. As we touched upon in the beginning, the truth is, anyone can pair and see benefits from doing it, regardless of the department one is in.

Enjoyed this article? There are tons of learning opportunities at EuroSTAR Online, taking place this month, Nov 17-19. Check out our programme of incredible speakers and book your ticket now!

——————————————————————————————–

Author: Jaime Jorge

I’m CEO and Co-founder of Codacy, an automated code review service that lets developers, teams and companies be more efficient and less frustrated. My background is in software engineering, where I hold a MSc in Software Engineering from Instituto Superior Tecnico. My company has allowed me to have experience in: fundraising, hiring, growth hacking, software engineering, PR, product development, customer development, sales. If you love your craft, contact me. Passionate people always make my day.

Rik Marselis: My Experience at a EuroSTAR online conference

October 14, 2020 by Fiona Nic Dhonnacha

Rik Marselis: My Experience at a EuroSTAR online conference

Curious about what’s coming up at EuroSTAR 2020 Online? How it all works? How you’ll connect with people on a virtual platform? We asked our programme chair Rik Marselis to tell us his experience from the Test & Quality Summit, a EuroSTAR-organised conference we held in September.

Here’s what Rik had to say:

The Test & Quality Summit was the first time I used the Hopin online conference platform (where EuroSTAR will also take place) – and it was a very positive experience.

I have become quite accustomed to working from my home office and have done my fair share of video meetings and online webinars.

But this kind of online conference platform has so many more features to offer.

Starting with navigation: the menu bar makes it easy to visit all the different ‘areas’ of the conference – the main stage, sessions (bonus talks), expo, and networking.

The main stage is of course where the programmed presentations are broadcast. But to get the real ‘conference feeling’, the other items on the menu are also important.

For example, the expo where the exhibitors had their virtual booths. I visited several of these booths: some featured product presentations, while I had good conversations with others using the built-in video-calling facility. In one conversation in particular, a few of us came together, which resulted in a meaningful exchange of views and ideas.

A feature that I really liked was the Speed Meeting. This is where you click to meet a random person to chat with. I just clicked the button to indicate that I was open to a meeting, and then I was connected to a random attendee.

To my – and her – surprise, the first random connection was with someone I’ve known for many years: Dorothy Graham. So, the 3 minutes for this speed meeting was far too short, but it was very nice to chat to her!

I also spoke to attendees that had watched my keynote presentation and wanted to know more. One person had a concrete practical problem in his job, and we were able to talk about a possible solution.

Luckily, the platform offers a variety of opportunities to contact people, so if the 3 minutes of the speed meeting is too short, we could just enter another room and connect via a 1:1 video chat feature!

At the Test & Quality Summit there were no parallel presentations, but there will be at EuroSTAR Online. Which means even more engagement and access to lots more sessions and talks.

I was pleasantly surprised by the direct interaction I had with attendees during my speaker presentation. Everybody can ask questions in the chat feature, and since my presentation was recorded to assure the quality, I could answer questions by text throughout, as well as coming on live for the official Q&A, which gave a whole new dimension to the interactivity of the conference.

There were lots of ways the platform captured the community feeling of a live conference. For example, the table quiz at the end of the day, the way you could virtually walk to the reception desk to ask questions about the programme, the organization, or whatever else you have a query on; and how you could travel from room to room.

All in all, the online conference was a great experience, and now I’m really looking forward to EuroSTAR Online in November: to enjoy the community feeling, and exchange ideas and knowledge about our fantastic quality & testing profession.

Rik is the Programme Chair of EuroSTAR 2020 Online this November. Together with his committee Mette Bruhn-Pedersen, Marta Firlej and Zeger Van Hese, they have created a full line-up of incredible speakers giving insights on all the topics you care about, including agile, DevOps, automation, test management, and lots more.

Introduction to Exploratory Testing

October 12, 2020 by Fiona Nic Dhonnacha

Exploratory Testing

Although test automation is the biggest trend in software testing right now, only focusing your strategy on automation isn’t going to guarantee you a fool-proof QA process.

By diversifying your testing strategy with different methods, you’ll be able to cover more ground (i.e. untested code) and more unexpected discrepancies to your code and product.

Exploratory Testing should be a part of your testing strategy because it will test the effectiveness of your existing tests, discover code discrepancies, and alleviate bottlenecks where bugs hide the most.

In this post, QA Software Engineer, Pekka Pönkänen, tells us how he effectively performs Exploratory Testing and his advice on making the most of your sessions.

Why Exploratory Testing is important

In 2018 I walked the length of Japan, and one of my goals for the trip was to explore the country and its rich culture. During the trip, I decided to walk in different routes other than just following Google Maps, and as a result of that I had many exciting adventures. Undoubtedly, without having the curiosity to explore, I would have missed many unique places and interesting conversations with locals.

I firmly believe that in order to find new ways of seeing and experiencing the world, you need to be brave and curious about the unknown. The same goes for software testing. Always following the same paths, or tests, will get you expected results. On the contrary, if you go on an exploratory session of your application, you’ll be amazed to discover just how many bugs could be hiding or how much you can improve the functionality for the user.

If you want to try Exploratory Testing yourself, consider this your starting point.

What exactly is Exploratory Testing?

The term “Exploratory Testing” means that you are exploring the application and how it performs after different actions.

To truly understand the concept, it is essential to dig deeper into the roots of the terminology. The term “Exploratory Testing” was introduced in 1984 by Cem Kaner.

“Exploratory software testing is a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the value of her work…”

James Bach’s 2003 paper, “Exploratory Testing Explained”

Through exploratory testing, your goal is to find out how a specific area of an application is working while using your skillset to provide valuable feedback to your team. You want to find the nastiest bugs under the hood and make sure that nothing critical or dangerous can happen in the app.

Preparing for Exploratory Testing

Before starting the testing run itself, it’s good to have tools to write down ideas, bugs, and defects. Personally, I like classic pen and paper and bug-tracking software to write down thoughts and plans for the future. During the run, you will see application logs, automation ideas, new approaches for new testing runs, and bugs that need to be fixed. Having good software that captures images, videos, and notes can be very helpful in centralizing your findings and sharing your insights with your team.

Keep in mind that your notes do not need to be the most delicate piece of art. What’s important is that you can gather a small story around it for your teammates or stakeholders after the session. I have heard very successful use cases with testers doing mind mapping during exploratory testing. Having this visual aid in the process can be valuable to build off of your ideas and create themes.

Identify your goal

The first thing to get started in exploratory testing is to define what to test. It can be a known bottleneck, possible risk, new feature, or an area which has a lot of bugs.

As a software tester, you may know the places to look, and the development team can define the areas which need more attention. When planning the testing, remember not to make it broad so that you don’t lose focus. Here are a few examples to get you started:

What to do:

Explore catalog page with a screen reader to verify page accessibility
Explore login process with iOS gestures to verify that functionality is accessible

These tasks can be timeboxed and can be done in one session and short enough to be focused.

On the other hand, you don’t want to choose a task that has too many options or paths to follow. The best way is to keep it simple and focus on smaller tasks.

What not to do:

Explore all possible mobile security issues to the system to discover any security-related threat

Once you’ve identified your goal and prepared your tools, here are the steps you can follow to complete an Exploratory Testing session:

1. Prep your session

After selecting an area to explore, design the test session. Once you know what to explore, you’ll get a flood of ideas about how to test different aspects — make sure to keep track of everything that comes to mind so you have a solid plan before you start testing. Write down your mission and prepare the notes about the way you want to proceed.

2. Setup the testing environment

Check that you have all credentials and access to enter the testing environment. Testing is pleasurable when you can focus on the testing itself, and when you don’t need to worry about usernames or unreachable servers.

3. Timebox and execute

Depending on the task, open the suitable logs, and monitor tools to log your actions during testing. Application logs are crucial to provide valuable information when things go wrong. While executing, keep your objective in mind, write notes, be systematic, collect info, gather ideas for the next sessions, and most importantly learn and explore your product.

Exploratory testing is more of a mindset than a framework

Exploratory testing is in fact a skill which is developing all the time while your skillset as a tester is evolving. The beauty of testing is that you never get bored of it because there is always room for improvement. Be curious about the application, try different approaches to execute testing, learn about your software, and share the knowledge.

At the end of the day, software development is a team sport!

Inform others about the state, risks, and any other concerns. Share your mind map as well as any evidence that you collected like videos, images and notes. You don’t have to have all of the answers, but sharing them with your team will also help others discover themes and insights which you wouldn’t have known otherwise.

——————————————————————————————–

Author: Pekka Pönkänen

Xray Contributing Writer | QA Engineer

6 strategies for building AI-based software

October 1, 2020 by Fiona Nic Dhonnacha

Building AI-based software

Developing software that incorporates artificial intelligence (AI) can be unpredictable, and you need a unique set of knowledge and skills to code, test, and make sense of the data. What’s more, tuning the system can take time, and the decisions AI-based software makes can sometimes be difficult to explain.

My organization specializes in developing software test automation tools that help users develop tests that run on different platforms, such as desktop computers and mobile devices. We wanted to make it even easier to write and run these tests, and avoid having to customize the test for each platform.

Our research led to adopt natural-language processing, which allows users of our software to describe a test using simple English, and computer vision with optical character recognition to identify the objects on a screen.

Here are the lessons we learned that you can apply as you incorporate AI concepts into your products.

Make data an integral part of planning

An artificial neural network (ANN) is a layered structure of algorithms designed to use data to make intelligent decisions without human intervention. We incorporated an ANN in our system, fed it with hundreds of thousands of data samples, and let it do its magic to make informed decisions.

In a system that’s heavily based on data, planning is essential. We had to address:

What data we needed to train the model
How to acquire, clean and classify that data
How to obtain additional data from customers

This required expanding the role of the product management team, which traditionally focuses on the features and capabilities of the product, to include overseeing the data-related aspects of the system. That included defining the scope of the data, the acceptance criteria for the data, and how data was to be used within our AI models.

Lesson learned: Data must be front and center of everything your team does, and your product managers must become familiar with the AI techniques your team is using in order to ensure consistency and reliable outcomes.

Decouple the AI model from your product

Developing and tuning an AI model can take a long time. If your application is tied closely to the model, you can only progress at the speed of the model’s development.

The AI model should be decoupled from the rest of the system and treated as a separate pipeline. This allows each piece of the system to progress at its own pace, and you can apply updates to the AI model independently. This has two key benefits:

You can develop and test your main product independently of the model, giving you fast feedback on product features unrelated to the AI portion of the product, and you can continue developing and training the AI model without being impeded by unrelated issues, such as a code change to the main product that breaks the build and holds everyone up until it’s resolved.
You can release your main product and the AI model at different cadences. This is particularly significant for users of our on-premises product, since they can install the product once and apply subsequent updates to the AI model without going through an extensive upgrade process. Given that the nature of AI models is to continuously learn, adapt, and improve, this is an important capability that allows our users to stay on the cutting edge of AI without having to wait for updates to the entire product.

Designing the system correctly to allow the AI model to be developed and deployed separately is a crucial capability that you should tackle early. Our release timeline now consists of two parallel timelines; one for the product, and one for the AI model updates.

Create cross-functional, multi-disciplinary teams

After we decoupled the AI model from the main product, our teams could develop and test it independently. But we also needed to test the system as a whole, with all of the components deployed and working together. For effective end-to-end testing, you need expertise in both AI and software testing.

We created cross-functional teams that included software engineers, data scientists, data analysts, testers, architects, and the product manager. This gave us the best of both worlds—we have experts in designing and developing AI models working alongside our software engineering and software testing specialists. In this way we can leverage the knowledge and experience of the entire team to develop, test, and deliver each component independently, as well as test the entire system holistically.

This approach has helped to cross-pollinate specialized knowledge across the team, so that our developers and testers have come to understand AI better, and our AI experts have learned to become better developers and testers.

Understand that explaining results in an AI system can be challenging

We like to think of our deep learning system as a black box that knows how to think and make decisions, but sometimes it makes decisions we weren’t expecting. When a regular software system does something unexpected, you can debug it. It might take time, but you’ll figure it out. But in an AI system, it’s almost impossible to determine the combinations and sequences of data and logic that led to a decision.

Lesson learned: The most efficient way to influence a model’s decisions is through supervised trial and error, coupled with guidance from the AI experts who understand how the model works, and who can guide the learning and tuning process toward more accurate results.

Expect longer cycle times when building the product

Traditional software products compile quickly—even large enterprise software products complete a build in no more than a few hours.

AI models are different. Training a neural net first involves gathering data samples, and then cleaning and tagging the data, which can take days, depending on the quantity and quality of the data you need. Only then can you start the training process, which can take several days for each training cycle. In our case, it takes about three days on a machine with a powerful processor to train just one model.

This is a major motivation for splitting the AI model out from the rest of the product, reducing dependencies and making it a separate and independent pipeline, as discussed above.

Retrain your AI models with customer data

It’s impossible to achieve 100% accuracy and zero defects in an autonomous, continuously improving, self-learning system. We train our AI models extensively in our own labs, but when the model is exposed to the customers’ environment, it has to make decisions about something it may not have seen before. The most effective way to tune the system so that it makes the best decisions is to augment the model’s training data with the customer’s data.

We work with our customers to improve the accuracy of our systems in their environments by obtaining their approval to use their data to retrain and optimize our models. This helps the model make better decisions, and creates better outcomes for our customers.

Apply these strategies to your own AI development

The software industry is undergoing an AI revolution, and vendors are adding new AI capabilities to their products every day. My organization has made significant adjustments to the way we develop and deliver software, and we have restructured our teams to include experts in AI—something you’ll need to do as well. We also work more closely than ever with our customers to learn from their environments and improve their outcomes.

AI development might be challenging, but it’s worthwhile. If you’re joining the AI revolution, make sure you apply these strategies to your software development process to get the most out of it for your team, your product, and your users.

This story was originally published on TechBeacon.

Want to know more about AI and how to apply it to your software testing? Check out EuroSTAR Online – we’ve got a programme packed with all of the topics you care about.

——————————————————————————————–

Author: Jecky Toledo, R&D Director, Micro Focus, Functional Testing

As Research and Development Director at Micro Focus, Jecky Toledo leads the groups responsible for the company’s functional testing and mobile testing portfolios. He has 20 years’ experience building and managing development teams using various methodologies, practices and delivery methods. Most recently, he has been leveraging the power of artificial intelligence and the transformation that AI-based systems bring to the entire software development lifecycle. Jecky trains in martial arts in his spare time, and is a father of three.